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The Mission Planning and Analysis Division (MPAD) of NASA is responsible 


for deve3.oping flight plans, performing flight design, for all manned space 
flights. Flight Design is the selection or development of time lines for 
vehicle trajectories, attitudes, and consumable usage. With the advent of 
the Sh'v.ttle Transportation System (STS), studies have shown that the flight 
design procedures and support software used for earlier programs (Gemini, 
Apollo, Skylab and ASTP) are not adequate to support the much higher flight 
rates anticipated with the Shuttle Program. In addition, the planning 
environment must be standardized to a degree not achieved in the past. 

A review of the flight planning tasks indicate the need for new 
concepts for performing the flight design function. A computer based system 
is needed that exhibits the following characteristics: 
o Interactive computations 

o Multiple concurrent user support 

o Useable by a variety of skill levels 
o Data Base interface 

o Launch-through-Landing flight design capability 
o User control over system function sequences 
o Independence of individual computational processors via 
standardized and generalized interfaces 
o Independent concurrent development of major components 

(processors) 

A NASA/IBM effort developed a comprehensive user interface technique and 
dialogue which in turn helped to establish detailed user requirements for 
such a system. This system is designated the Flight Design System II 
(FDS-Il). 
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Recent advances in computer technology have produced small computers 
(mini's) having many of the capabilities of the Older, larger generejl 
purpose computers. As a cost effective measure, NASA determined that this 
new technology should be evaluated as a candidate host for FDS-II. Sub- 
seciuently, IBM was given the task of evaluating the FDS-II requirements in 
this area. 

(?. Task Objectives 

The objectives of this task were to support NASA/MPAD to: 

1) establish a technique for a computer based, time shared, inter- 
active flight design system based on the accepted FDS-II user 
interface. 

2) implement selected portions of the technique as a bench program 
(FDS-I) to establish a base for evaluation of FDS-II requirements 

3) use FDS-I to provide an objective evaluation and refinement of 
FDS-II requirements. 

3. Task Approach 

The general task approach was to analyze flight planning requirements, 
define a candidate computer system architecture that supports presently 
defined user/computer dialogues, implement various components of the dialogue 
and provide objective evaluations of, as well as suggest refinements to, the 
requirements for the proposed FDS-II. To accomplish this task, four sub- 
tasks were established that could be easily monitored. Each task had a 
defined deliverable product. 
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3.1 Subtasks 

3.1.1 Architecture 

The goals of the architecture suhtask were to: 

1) Define a candidate architecture for a GFE mini-computer 
system consistent with published FDS-II computational and 
user dialogue requirements, 

2) Assist NASA in prioritizing the components and functional 
elements of the architecture for development by identifying 
those elements necessary to evaluate FDS-II requirements. 

The purpose of the architecture is to evaluate FDS-II Level 
A and B requirements, prior to Level C requirements definition. 

3.1.2 Design (Executive PDL) 

The design subtask was to produce program design logic consistent 
with the prioritized functional elements of subtask 3.1.1. This design 
was restricted to the FDS Executive portion Of the architecture. NASA 
personnel were to implement applications derived from existing flight 
design computer programs. 

3.1.3 Implementation (Executive Code) 

The implementation subtask was to implement the designed program 
elements of subtask 3.1.2 on the specified GFE computer and assist. NASA 
in evaluating FDS-II requirements. 

3.1.Jj Analysis (FDS-II Analysis) 

The analysis subtask was to document recommendations for FDS-II 
computer system requirements resulting from the FDS-1 development 
experience. Recommendations were to cover basic hardware, operating 
system, system support software, and applications executive design. 
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3.2 Schedules 


The FDS Requirements Evaluation Frogrora task was active from 
November 29, 1976 to October 1, 1977. (The final deliveries were 
accomplished on October 7, 19770 A schedule by subtask is presented 
in Figure 3-1. 

3.3 Status Reviews 

To maintain comprehensive communications between NASA arid IBM 

during the course of the task, bi-weekly on-site status reviews were 

♦ 

held. A documented status report v/as presented by IBM to NASA at each 
of the 19 meetings. The reviews covered the following areas: 

1) Administrative 

2) Configuration Control 

3) Financial 

3.3.1 Administro.tive Status 

Each subtask was addressed as required in terms of current status, 
outstanding issues, and immediate as well as overall schedules. 

3.3.2 Configuration Control 

A mechanism was established and used by which problems and/or 
desired modifications would be reported for hardware, delivered soft- 
ware, and published documentation. A two function form (FDS Problem - 
Deviation - Query Form (PDQ)) Was developed by which a problem, change, 
or query could be both described and answered (see figure 3-2). All 
lodging of PDQ's and the coordination of their disposition was accom- 
plished through a close interaction between designated NASA and IBM 
coordinators. The use of the PDQ forms provided visibility and a 
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historical record of problem areas, desiBn/requirement changes, and 
items for future consideration. Open PDQ's were die^ussed at the bi- 
weekly status reviews. 

3*^t Financial 

Total funding of the task was from two sources. The majority of 
the funds were RTOP funds with supplemental funds coming from DTMO. 

Funds budgeted and spent are sumiiiarized below; 


RTOP FUNDS 

113,900 

DTMO FUNDS 

23,000 

TOTAL 

136,900 

EXPENDITURES 

128.000 

REMAINING 

8,900 


Total manhours expended = 4,400 
It.O Tank Results 

The objectives of the FDS Requirements Evaluation Task were to 
design a computer technique accomplishing interactive Flight Design and 
to implement sufficient code to determine the feasibility of the design, 
These objectives were achieved with the planned output of the four sub- 
tasks. The MPAD's Hewlett Packard 21 MX mini-computer and associated 
peripherals were used as the development computer for the task. 
l;.l Architecture Subtask 

The result of the architecture subtask was the design of a system 
consisting of two classes of program: 

l) A library of applications processors, each designed to do a 
specific flight design computational or analysis function 
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2} an FDS executive that provides the following capabilities: 
o Concurrent use of the system by multiple Independent 
users 

o User communications with the system, both executive 
and processors 

o Ability to execute the applications processors, indivi- 
dually or in a sequence 
o Communications between processors 

0 Data management and retention of data from one terminal 
session to another. 

o Flexibility to easily extend system capabilities through 
the addition, modification or deletion of processors 
As the design effort progressed, the following executive 
software functional areas were defined; 

Multiple Tasking and Management 
0 Configuration Manager (dynamic system configuration) 

0 FDS Manager (dynamic data management and processor 
sequencing) 

o Attention Functions (Asynchronous program status and 
control) 

o System services (program to program communications) 
Executive Primary Functions 
o Terminal Communications and Lexical Analysis 

o Interface Table Editor (processor input/output definition) 
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o fjoquefu'e Tublo KflJtor (apoctfluaUon (if fironoarjor 
execution uequcncen) 

o Execution Controller (automatic processor sequencing) 
Tho output product of the architecture suhtask was the generation 
of section 6.2 of the FES-I System Design Document entitled > 
"System Architecture and Executive." This documentation was 
delivered to NASA on December 3, 1976 and subsequently updated to 
keep it current with the actual implementation. 
k,2 Design (Executive PDL) Subtask 

As tH?-' architecture phase of the task matured into the design 

phase, f. even of the eight functional software areas defined In ^.1 re- 
solved into 1»J| program; modules. To date, the Sequence Table Editor 
functional area has not been implemented. Before coding each routine, 
a complete detailed design was developed using the Program Design 
Language (PDL). Each design was then reviewed by at least one other 
member of the task. By keypunching the PDL statements on cards and 
utilizing a batch program (PDLIST), a structured PDL listing was 
generated for each program. These listings constituted the design 
documentation for each program and were the deliverable output of the 
FDS-I system, i.e., Build I (6/30/77), Build II (8/31/77), and Build 
III (10/7/77). 

1».3 Implementation (Executive Code) Subcask 

The implementation subtask was the mechanization of the design 
for each module into executable code. Both FORTRAN and assembler 
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lanBua^e were used in the task. Of the Jill modules, were coded in 
assembler language and 29 in FORTRAN. In total, 1|81|8 lines of PDL and 
92Ji9 source lines were generated. Each module was unit tested by the 
originating programmer. As the modules were integrated into a system, 
comprehensive independent verification was performed at the system 
level. A complete set of program listings and disk files containing 
all of the source, relocatable, and executable code was delivered for 
eacli Incremental system i^elivery. 

J|.1| Analysis (FDS-II Analysis) Subtask 

After the first Increment of FDS-I had been coded, tested, and 
delivered, several discussion sessions involving all task personnel 
were held in order to consolidate ideas on requirements for FDS-II. 
Topics covered were: 
o Hardware 

o Operating System 

o System Support Software 

o Documentation 

0 Executive Design 

Recommendations were gathered for each function and each was assigned 
a relative importance, i.e., 

1) Mandatory 

2) Necessary for reasonable development 

3) Highly Desirable 

t) Desirable 
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The resulting document was published and distributed to NASA on 
August 12, 1977 . 

4, 5 Related Task 

In order to take advantage of the program modules implemented 
under this task, a companion task (Flight Planning System Develop- 
ment) was performed concurrently^ This task developed additional 
support and utility software. The combined outputs of the two tasks 
together with applications software developed by NASA will result in 
a system capable of supporting interim operational Plight Design 
until FDS-II is completed. 

5 . Future Considerations 

Items for future consideration include refined and extended 
requirements identified during the implementation phase of FDS-I and 
items identified in the FDS-I design, but due to priortization of 
components, were not implemented during the FDS Requirements 
Evaluation Task. Yet to be considered are: 

1) Batch Execution - the capability to schedule a Job to be 
run in the background asynchronously with the Interactive 
FDS. 

2) Mixed Formats - the capability of supporting user defined 
data arrays containing a variety of data formats, e.g., 
integer, double precision, character data, etc., that occur 
in predefined fixed patterns. 
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Extended Prompto ~ a capability whereby a user may, at any 
point in his dUilOflue with the system, request additional 
‘tutorial information by entering a simple request, e.g. , a 
? symbol. 

Sequence Table Editor ~ the capability for users to generate 
and maintain tables in which a series of processor execution 
commands are stored. This provides the users with the 
capability of storing and executing standard sequences of 
commands as logical entities, i.e,, standard flight phases. 
Serai-!-Automatic and Automatic Mode - the execution of series 
of processors using all or part of specified prestored 
sequence tables. 

Utility Processors - a set of processors that allow the user 
to accomplish on-line storage allocation, basic mathematic 
computations, execution sequence control, message outputs, 
and parametric data generation. 

Job Acco\inting System - the capability for PDS to automatically 
collect and store statistical information about the useage of 
of the system, length of terminal session, CPU usage, I/O 
frequency, etc. 
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